United States Patent twj 

Bernstein et al. 



Ill 



USO05297249A 

[li] Patent Number: 
[45] Date of Patent: 



5,297,249 
Mar. 22, 1994 



[54] HYPERMEDIA LINK MARKER ABSTRACT 
AND SEARCH SERVICES 



Inventors: Keith Bernstein, Washington, D.C.; 
John A. Stephens, Boyds, Md. 



[75] 

[73] Assignee: 



International Business Machines 
Corporation, Annonk, N.Y. 



[21] Appl. No.: 606,309 

[22] Filed: Oct. 31, 1990 

[51] Int. CP G06F 3/14; G06F 15/00 

[52] U.S. Q 395/156; 395/155; 

395/157; 395/161; 395/600; 364/DIG. 1; 
364/286; 364/286.1; 364/286.2; 364/286.3; 

364/282.1 

[58] Field of Search 395/600, 155, 156, 157, 

395/159, 161, 144, 145, 146; 364/419 

[56] References Cited 

U.S. PATENT DOCUMENTS 

4,692,757 9/1987 Tsuhara et al 340/721 

4,893,256 1/1990 Rutherford et al 395/154 

4,914,586 4/1990 Swinehart et al 395/600 

4,931,950 6/1990 Ish et al 395/11 

4,982,344 1/1991 Jordan 395/157 

5,204,947 4/1993 Bernstein et al 395/157 

FOREIGN PATENT DOCUMENTS 

88119250.4 of 0000 European Pat. Off. . 

OTHER PUBLICATIONS 

N. Meyrowitz, "Intermedia: The Architecture and 
Construction of an Object-Oriented Hypermedia Sys- 
tem and Applications Framework", OOPSLA 1986 
Proceedings, Portland, Oreg M Sep. 1986. 
N. Yankelovich et al,, "Intermedia: The Concept and 
the Construction of a Seamless Information Environ- 
ment," Computer, vol. 21 Iss. 1, pp. 81-96, Jan. 1988. 
N. Yankelovich et al., "Connections in Context: The 
Intermedia System," Proceedings of the Twenty-First 
Annual Hawaii International Conference on System 



Sciences, vol. II Software Track, IEEE Computer So- 
ciety Press, pp. 714-24, Jan. 1988. 
Young, Jeffrey S., "Hypermedia," Macworld, Mar. 
1986, pp. 116-21. 

"Hypertext II" by Jakob Nielsen, SIGCHI Bulletin, 
Oct. 1989, vol 21, No. 2, pp. 41-47. 
"Hyperhyper" by Jakob Nielsen, SIGCHJ Bulletin vol. 
21, No. 1, Feb. 1989, pp. 65-67. 
"Trip Report: Hypertext *89" by Jakob Nielsen SIG- 
CHI Bulletin vol. 21, No. 4, Apr. 1990, pp. 52-61. 
"Sun Link Service: Protocol For Open Linking" by 
Amy Pearl, Hypertext 1 89 Proceedings Nov. 1989, pp. 
137-146. 

"An Overview of Hypertext & Hypermedia" Concept <& 
Issues EP10-010-701, Nov. 1989. 
"Multimedia Authoring Systems" PC Magazine Jul. 
1990, pp. 163-192. 

"Desktop Multimedia: You Ain't Seen-Nothing Yet" by 
Eric Bendedr, PC World Mar. 1990fpp. 191-196. 
"Hypted" by Steve Ditlea, PC/Computing Oct. 1990, 
pp. 201-210. 

Primary Examiner — Paul V. Kulik 

.Attorney, Agent, or Firm— Whitham & Marhoefer 

[57] ABSTRACT 

A set of hypermedia linking services enable client appli- 
cations to incorporate hypermedia capabilities in an 
open system architecture. The users are provided with 
a consistent hypermedia interface completely managed 
by the hypermedia services and not by the client appli- 
cation itself. The graphical user interface includes meth- 
ods for menu handling, dialog box presentation and 
pointing device message handling, e.g., mouse message 
handling. Normal hypermedia activities such as object 
management, object creation, object deletion and object 
modification is provided. In addition, an open system 
searching mechanism is provided to satisfy broad non- 
context requests for information by the user without 
sacrificing the advantages of an open hypermedia envi- 
ronment. 

14 Claims, 27 Drawing Sheets 
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presenter). Thus, the term "document" is not limited to 
HYPERMEDIA LINK MARKER ABSTRACT AND a text file but may be text, bitmap graphics, a spread- 
SEARCH SERVICES sheet or some other data presentation. In some cases, 

other objects are considered as "documents" by LMS. 
CROSS-REFERENCE TO RELATED 5 These objects include audio files, motion video files and 

APPLICATIONS clips, and a series of image files (i.e., slide shows). 

The invention disclosed in this application is related End User Interface (EUI): The methodology, includ- 
in subject matter to application Ser. No 07/741,220, ing devices, by which an end user interacts with a sys- 
filed Aug. 2, 1991, now abandoned, which was a contin- tem, system component, and/or system application, 
uation of application Ser. No. 07/273,527 Nov. 18, 1988, 10 Graphical User Interface (GUI): An EUI which is 
by P. Y. Chang et al., now abandoned, and assigned to graphical; for example, end user interactions with the 
the assignee of this application. The invention is also system via windows, icons, menus, pointing devices, 
related to that of our co-pending patent application Ser. etc. 

No. 07/606,320, filed concurrently herewith entitled Hypertext/Hypermedia: In the generic and simplest 
"Application Independent (Open) Hypermedia Enable- 15 scnsC) t h cse terms mean touch and get. They embody 
ment Services", now U.S. Pat. No. 5,204,947, also as- the notion of an end user being able to touch (e.g., using 
signed to the assignee of this application. The disclo- some fcn d 0 f pointing device) an object (e.g., a word, 
sures of the foregoing applications are incorporated phrase, graphical object, etc.) and thereby cause one or 
herein by reference. more associated information entities to be obtained. A 

BACKGROUND OF THE INVENTION 20 surve y of hypertext systems is provided in "Hypertext: 

An Introduction Survey" by Jeff Conklin, IEEE Corn- 
Field of the Invention puUr ^ September 1987, pp. 17-41, and "An Overview of 
The present invention generally relates to a software Hypertext and Hypermedia", Concepts & Issues, 
facility for providing relatively seamless integration of McGraw-Hill, November 1989. 
"hypertext/hypermedia" services into existing, as well Link: An object which associates a point in one docu- 
as new, computer program applications and, more par- ment with a point in another document (or different 
ticularly, to support for abstract (i.e., summary and/or point in the same document). Links may be bidirectional 
keyword) authoring and searching as part of the and therefore may be followed from either end. 
"hypertext/hypermedia" services. ^ Link Manager Services (LMS): A complete inte- 

Definition of Terms « r f ed * et °| : hypertext/hypermedia services 

Link marker: A (typically) visual indication to the 

The following terminology is used throughout this end useff contained within a document, indicating that 

disclosure. t h ere ma y De one or more links present at this point (the 

Abstract: A text object consisting of keywords, link mar ker's location) in the document. If there are 

phrases, and/or statements, which summarize the im- links emanat j ng f rom a ij n k marker and the link marker 

portant information that would be found at a link i s triggered (e.g., by the end user with a mouse), the link 

marker with which the text object is associated. marker's links may be navigated. LMS provides link 

Application: A computer program, other than an mar kers that can have many different appearance styles, 
operating system, such as a word processor, spread- inchlding (l) pus h-buttons which may optionally con- 
sheet, database management, graphics designer, and the «> ^ (2) black frames which allow the end ^ t0 
like. As used herein, an application program is also see thrQUgh ^ , mk marker > s framed ^ to the cUen t 
referred to as a presenter. application's underlying rendered data, (3) highlight 

Application Programmmg nterface (API): A means ^ which, like black frames, provide for transpar- 

by which a program may call a service . ^ framcs which afC teed t0 

Chent application: An application (presenter/pro- « * yuseful compa red to black frames 

gram) which uses LMS services when some ofthe underlying data may be black or very 

Context menu: Often referred to as popup menus, , . . * , . ... . 4 ' f. . . ^ . ; 

A . -ii j r n wi * dark), (4) highlight areas which are also transparent in 

context menus are visually and functionally similar to " v 1 * * . , . . . , 4 ... . r 

pull-down menus, but are not tied to the action or com- *f ^FT™ f ^ t J ^ 

mand bar. They may appear at arbitrary positions in 50 tWe, but the colors of the underlying data will be 

windows. Additionally, while the contents of a pull- changed (also sometimes known as reverse video, e g., 

down menu typically do not change based on the state all underlying black color is changed to white all white 

of the application at any given time (though they may color 15 changed to black, all blue color is changed to 

be enabled or disabled/grayed), the contents of a con- yellow, etc ), and (5) invisible which are truly invisible 

text menu, on the other hand, are dynamic, and change 55 with regard to any occlusion of the underlying data, 
based on the state of the application; in other words, Mouse: The term mouse, when used in this document, 

they are context sensitive. For instance, if a context reall V refers to an V W« of operating system supported 

menu contained an item which said, "Save", when the . pointing device including, but not limited to a mouse, 

context menu is displayed and no data has been modi- t« ck ball, lightpen, touch screen, and the like. Also, the 

fied, the "Save" option would not appear in the menu. 60 screens, keyboard and mouse operations, menus, etc. 

Context menus are typically displayed when the end with which an end-user interacts with when using an 

user clicks a mouse button over some window. Context application. 

menus typically contain similar function to pull-down Navigation: The following, or traversal, of a link, 
menus, but only include those items which are relevant Open system: A hypermedia system which allows 

to the object clicked on, at a given time. 65 any application (presenter) to participate in linking. 

Document: A named set of data (such as a text file, an Such applications need not be aware of documents and- 

image file, a video passage, etc.) usually, but not neces- /or presenters at the other ends of links, thus allowing 

sarily, discernible by an end user (when rendered by a for the seamless integration of applications and applica- 
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tion-rendered data developed totally independently Brown University, which also provides no facility for 

from one another. enabling other (non-Intermedia-supplied) applications 

Presenter: An application which renders data (e.g., (presenters) with hypermedia capabilities; and Link- 
text files, image files, audio passages, etc.) for an end Way 2.0 by IBM Educational Systems and which pro- 
user. 5 vides no facility for enabling other (non-LinkWay-sup- 

Pull-down menu: These are the menus which are tied plied) applications (presenters) with hypermedia capa- 

to the action bar (menu bar) at the top of a window. bilities. 

These menus may also contain submenus, which are Sun Link Service by Sun Microsystems is the only 

known as cascade menus. other open hypermedia system known to the inventors 

nF^rRiPTinhJ of thf prior art 10 35 an avaiIable P roduct Sun ' s facilit y does P rovi ? e a ■? 
DESCRIPTION Or THE PRIOR ART of services which ^low other (non-Sun-supplied) apph- 

A number of hypertext/hypermedia systems are pro- cations to be enabled with hypermedia capabilities; 

grammed in an object-oriented programming language, however, this enablement is neither seamless nor easy, 

such as Smalltalk and C++. The former was devel- Additionally, the Sun Link Service does not manage the 

oped at the Xerox Palo Alto Research Center (PARC), 15 end user interface for the hypermedia capabilities, 

and a good description of that language may be had by which means that each application must implement its 

reference to the textbook by Adele Goldberg and own notion in that regard. Additional information on 

David Robson entitled Smalltalk-SO: The Language and this product may be found in an article entitled "Sun's 

Its Implementation, Addison-Wesley, 1983. The C+ + Link Service: A Protocol for Open Linking" by Amy 

language was developed by Bjarne Stroustrup of 20 Pearl on pages 137-146 of the Hypertext '$9 Proceedings. 

AT&T Bell Laboratories and described, for example, in In addition to the foregoing, several other products 

his book entitled The C+ + Programming Language. which implement hypertext/hypermedia capabilities 

Addison-Wesley, 1986. Among the advantages of Ob- were reviewed in the October 1990 issue of PC/Com- 

ject-Oriented Programming Systems (OOPS) are mod- puling Magazine at pages 201-210. These include Folio 

ular structure and object-oriented user interfaces using 25 Views 2.0 by Folio Corp., Hyperties by Cognetics 

icons. Further information on object oriented program- Corp., HyperWriter by Ntergaid, Spinnaker Plus 2.0 by 

ming and hypersystems may be obtained from "Design Spinnaker Software Corp., and Transtext by Max- 

and Use of Hyperdedia Systems" by Robert Akscyn of Think. Folio Views was reviewed as: "An information 

Knowledge Systems, Inc., Conference on Human Fac- management system that lets you compress 2 large text 

tors in Computing Systems, May 14, 1988, and "Interme- 30 files into a customized 'infobase' and create cross- 

dia: The Architecture and Construction of An Object referencing links." Nothing further is known of this 

Oriented Hypermedia System and Application Frame- product, however, the review suggests that this would 

work" by Norman Meyrowitz, IRIS, Brown Univer- not allow for linking between different presenters and- 

sity, OOPSLA Proceedings, September 1986. /or different types of data. This also suggests that no 

Insofar as the inventors are aware, there are no 35 method is provided for enabling other (non-Folio 

hypertext/hypermedia systems, or system services, Views-supplied) applications (presenters) with hy- 

which enable applications (presenters) to seamlessly and permedia capabilities. 

easily incorporate hypertext/hypermedia capabilities in Hyperties was reviewed as: "An interactive system 

an open system architecture, as well as automatically that lets you create hypertext documents and manuals 

provide a consistent end user hypermedia interface 40 from a variety of media, including existing files, online 

which is managed by the hypermedia services, and not information, scanned material and video." Hyperties is a 

the presenter itself. Additionally, even those hy- closed hypermedia system; e.g., one must use only the 

permedia systems which are somewhat "open" systems presentation facilities supplied by the product. Nothing 

cannot alter the user interface upon future releases with- further is known of this product, however, the review 

out requiring all hypermedia applications in the system 45 suggests that no method is provided for enabling other 

to be modified and rebuilt. (non-Hyperties-supplied) applications (presenters) with 

The prior art discussed below are representative of hypermedia capabilities, 

products and/or services which implement hypertex- HyperWriter was reviewed as: "A hypertext author- 

t/hypermedia capabilities. ing tool with audio and video capabilities and a limited 

HyperCard published by Apple Corp. is considered 50 scripting language." 
by many (including its author, Bill Atkinson) to not be Spinnaker Plus 2.0 was reviewed as: "A hypertext 
a hypermedia product, but rather an "application programming environment for developing and running 
builder" or "stack of cards". When viewed as a hy- custom information management applications." Al- 
permedia system (in that cards are linked" together) it though no more information than this is known, it ap- 
is a closed hypermedia system; e.g., one must use only 55 pears from the review that Spinnaker is more of an 
the presentation facilities supplied by the product. Hy- application generator program than a "true" hypertext 
perCard provides no facility for enabling other (non- product. 

HyperCard-supplied) applications (presenters) with Transtext was reviewed as: "A word processor that 

hypermedia capabilities. lets you create hypertext links to many other commer-. 

The SuperCard program by Silicon Beach Software 60 daily available applications." Nothing further is known 

is a HyperCard "look-alike", with more power than of this product, however, the review seems to indicate 

HyperCard. It provides stacks of "cards", as well as that unidirectional links out of the product may be es- 

application generation. Other examples of closed hy- tablished, which probably simply cause the launching of 

permedia systems include Guide 2.0 by OWL Interna- existing commercially available applications, simply 

tional, Inc. which provides no facility for enabling other 65 passing them user-specified parameters. 

(non-Guide-supplied) applications (presenters) with In addition, KnowledgePro by Knowledge Garden, 

hypermedia capabilities; IRIS Intermedia by Institute Inc., was reviewed in the November 1989 issue of Con* 

for Research in Information and Scholarship (IRIS), cepts & Issues, referenced above, as: ". . . while some 
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skill in programming is useful in becoming familiar with 
the product, its developers claim such skill is not a 
prerequisite to learning the program ... a programming 
environment that combines an expert system generator 
with hypertext ... It can read external files, call external 
programs, and be extended by routines written in other 
languages." In addition, the review also suggests that 
the programming environment/expert system generator 
combination could yield some sophisticated searching 
capabilities. However, nothing more specific is known 
either about the search capabilities or the degree of 
openness contained in the product 

Although hypermedia systems of any kind are, most 
fundamentally, information storage and retrieval sys- 
tems, they all have the distinction of providing for the 
establishment of the association of information in con- 
text, and its subsequent retrieval based on that context. 
For example, when an end user is reading a hypermedia 
document about nutrition and comes across, what in 
LMS terms is called a link marker, indicating that a 
Table of Nutritional Values will be shown to the reader 
if the link marker is triggered (e.g., activated via a point- 
ing device) and the reader activates the link marker, 
then the Table is presented to the reader. If the reader 
had been using the document in hardcopy form (e.g., a 
book) then the reader might have had to search for the 
Table using the index or some other cross-reference 
section of the document, and perhaps find multiple 
references for the Table, only one of which was for the 
actual Table. General purpose information storage and 
retrieval systems are well suited to the task of just such 
indexed/cross-referenced searching, but not necessarily 
in context. 

Why not be able to have both? In the November, 35 
1989 issue of Concepts 8c Issues referenced above, in an 
article discussing hypertext and hypermedia, the obser- 
vation is made that " . . adding multimedia capabilities 
will not solve all the problems associated with using 
hypermedia for data retrieval. What happens, for exam- 4Q 
pie, when users are not quite sure where to look for the 
information they seek?" (i.e., they can not find a link 
marker to trigger). What if the end user is viewing 
hypermedia information which results in an idea for 
which there are no guiding link markers currently being 45 
shown, but the end user wants to pursue information 
relevant to the idea? And what if the hypermedia sys- 
tem is an open system, such as specified by LMS, having 
independently developed hypermedia applications with 
different kinds of data? What open system searching 50 
mechanism can be built to satisfy the broad non-context 
requests for information without sacrificing the advan- 
tages of an application and data independent (open) 
hypermedia environment? 

SUMMARY OF THE INVENTION 55 

It is therefore an object of the present invention to 
provide abstract authoring and searching as part of 
"hypertext/hypermedia" services, using an open system 
architecture, for existing, as well as new, applications. 60 

According to the invention, there is provided a set of 
system link marker abstract services, which enable ap- 
plications (presenters) to seamlessly and easily incorpo- 
rate authoring and searching facilities for these serviced 
objects, consistent with the hypertext/hypermedia ca- 65 
pabilities in an open system architecture (as defined by 
LMS), as well as automatically provide end users with 
a consistent hypermedia link marker abstract authoring 



and searching EUI which is completely managed by the 
underlying services and not the presenter itself. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing and other objects, aspects and advan- 
tages will be better understood from the following de- 
tailed description of a preferred embodiment of the 
invention with reference to the drawings, in which: 

FIG. 1 is pictorial representation of a personal com- 
puter; 

FIG. 2 is a system block diagram of the personal 
computer shown in FIG. 1; 

FIG. 3 is a functional block diagram of the link man- 
ager services implemented on the personal computer 
shown in FIGS. 1 and 2; 

FIG. 4 A is a block diagram illustrating a marker to 
object (unidirectional) link, and FIG. 4B is a block 
diagram illustrating a marker to marker (bidirectional) 
link; 

FIG. 5 is a block diagram showing the functional 
relationship of Link Manager Services in an open sys- 
tem; 

FIG. 6 is a flow diagram showing the logic of the 
client application window, procedure; 

FIG. 7 a screen showing a document and marker 
before navigation; 

FIG. 8 is a screen showing a new document and 
marker after navigation; 

FIG. 9 is a screen showing a context menu when a 
mouse has been clicked on a document; 

FIG. 10 is a screen showing a context menu when a 
mouse has been clicked on a link marker; 

FIG. 11 is a screen showing a pull-down menu when 
a mouse has been clicked on LINK in the command bar; 

FIG. 12 is a screen showing a second pull-down 
menu when a mouse has been clicked on MANAGE 
MARKERS in the first pull-down menu of FIG. 11; 

FIG. 13 is a screen showing a third pull-down menu 
when a mouse has been clicked on CREATE 
MARKER in the second pull-down menu of FIG. 12; 

FIG. 14 is a screen showing a second pull-down win- 
dow when a mouse has been clicked on MANAGE 
LINKS in the pull-down window of FIG. 11; 

FIG. 15 is a screen showing a third pull-down win- 
dow when a mouse has been clicked on CREATE 
LINK in the second pull-down window of FIG. 14; 

FIG. 16 is a flow diagram showing the logic of the 
pull-down menu processing performed by LMS; 

FIG. 17 is a flow diagram showing the logic of the 
context menu processing performed by LMS; 

FIG. 18 is a flow diagram showing the logic of the 
non-menu command message processing performed by 
LMS; 

FIG. 19 is a flow diagram showing the logic of the 
create marker procedure performed by LMS; 

FIG. 20 is a flow diagram showing the logic of the 
marker window procedure performed by LMS; 

FIG. 21 is a flow diagram showing the logic of the 
window painting procedure which supports transparent 
or invisible windows; 

FIG. 22 is a screen print showing the location of an 
invisible marker (i.e., window) by reverse video high- 
lighting; 

FIG. 23 is a screen showing multiple, overlying win- 
dows to illustrate the procedure normally followed 
when a window is painted on the screen; 

FIG. 24 is a screen showing an example of an LMS 
dialog box for selecting a link marker style; 
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FIG. 25 is a screen showing another example of an components are attached and by which communication 
LMS dialog box for managing links; between the various components is accomplished. A 

FIG. 26 is a screen showing a third example of an microprocessor 22 is connected to the system bus 21 
LMS dialog box for initiating a search of the LMS and is supported by Read Only Memory (ROM) 23 and 
hypermedia database; 3 Random Access Memory (RAM) 24, also connected to 

FIG. 27 is a flow diagram showing the logic of the system bus 21. The microprocessor 22 in the IBM PS/2 
dialog box management procedure performed by LMS; series of computers is one of the Intel family of micro- 
FIG. 28 is a flow diagram showing the logic of the processors including the 80286, 80386 or 80486 micro- 
LMS database update procedure; processors, but other microprocessors including, but 

FIGS. 29A and 29B are a flow diagram showing the 10 not limited to, Motorola's family of microprocessors 
logic of the link marker and link database update proce- such as the 68000, 68020 or 68030 microprocessors and 
dure called from the procedure shown in FIG. 28; various RISC (Reduced Instruction Set Computer) 

FIG, 30 is an example of an LMS abstract authoring microprocessors manufactured by IBM, Hewlett Pack- 
dialog box; Sun Microsystems, Intel, Motorola and others may 

FIG. 31 is an example of an LMS abstract search 15 be used in a specific computer, 
results dialog box; The ROM 23 contains, among other code, the Basic 

FIGS. 32A and 32B are a flow diagram showing the Input/Output System (BIOS) which controls basic 
search logic according to the invention; and hardware operations, such as interactions of the disk 

FIG. 33 is a block diagram showing the functional drives and the keyboard. The RAM 24 is the main mem- 
relationships between LMS, an application and the 20 ory into which the operating system and application 
£T jj programs are loaded. A memory management chip 25 is 

connected to the system bus 21 and controls Direct 
DETAILED DESCRIPTION OF A PREFERRED Memory Access (DMA) operations, including paging 
EMBODIMENT OF THE INVENTION data between RAM 24 and a hard disk drive 26 and a 

The invention may be run on a variety of computers 25 floppy disk drive 27. 
under a number of different Operating Systems (OS). To complete the description of the system unit 11, 
The computer could be, for example, a personal com- there are three I/O controllers. These are the keyboard 
outer, a mini computer or a main frame computer. The controller 28, the mouse controller 29 and the video 
computer may a standalone system, part of a network controller 30, all of which are connected to the system 
such as a Local Area Network (LAN) or Wide Area 30 bus 21. As their names imply, the keyboard controller 
Network (WAN) or a larger teleprocessing system. For 28 provides the hardware interface for the keyboard 12, 
purposes of illustration only, the invention is described the mouse controller 29 hardware interface for the 
below as implemented on a personal computer, such as mouse 13, and the video controller 30 provides the 
IBM's PS/2 series, although the specific choice of com- hardware interface for the graphic display device 14. 
puter is limited only by memory and disk storage re- 35 The hardware illustrated in FIGS. 1 and 2 is typical 
quirements. For additional information on IBM's PS/2 but may vary for a specific application; that is, there 
series of computers, the reader is referred to Technical may be other peripherals, such as optical storage media, 
Reference Manual Personal System/2 (Model 50, 60 Sys- audio I/O, printers and the like. The invention is specific 
terns), IBM Corporation, Part No. 68X2224, Order No. cally directed to an enhancement to the Operating Sys- 
S68X-2224, and Technical' Reference Manual Personal 40 tern (OS) which controls or "runs" the hardware. As 
System/2 (Model 80), IBM Corporation, Part No. mentioned, the invention may be added to an existing 
68X2256, Order No. S68X-2256. OS or it may be integrated into the OS, but it will be 

The operating system on which a preferred embodi- assumed for purposes of this disclosure that the Ob 
ment of the invention was implemented was IBM's supports a GUI. Such an operating system is IBM s 
OS/2 with Presentation Manager (PM), but it will be 45 OS/2 with Presentation Manager (PM) on which the 
understood that the invention could be implemented on invention has been implemented, 
other and different operating systems and, more impor- The invention provides an open system which sup- 
tantly, could be integrated into, and therefore be a part ports and provides a consistent environment for a van- 
of, an operating system. For more information on IBM's ety of unrelated application programs, as generally 
OS/2 operating system, the reader is referred to IBM 50 illustrated in FIG. 3. In FIG. 3, the Link Manager Sys. 
Operating Systems/2, Version 1.2, Standard Edition Tech- terns (LMS) 31 is shown by way of example as support- 
nical Reference, IBM Corporation. ing five application programs including a spreadsheet 

Referring now to the drawings, and more particu- program 32, a word processing program 33, a motion 
larly to FIG. 1, there is shown a personal computer 10 video program 34, a graphical image program 35, and 
comprising a system unit 11, a keyboard 12, a mouse 13 55 an audio program 36. As will be described in more 
and a graphics display device or monitor 14. The key- detail hereinafter, the LMS 31 maintains via a ^base 
board 12 and the mouse 13 constitute user input devices, 37, stored for example on hard disk dnve 26 (FIG. 2), 
and the display device 14 is a user output device. The various links specified by the user to each of the several 
mouse 13 is used to control a cursor 15 displayed on the application programs. 

screen 16 of the display device 14. The Graphic User 60 The database 37 is a collection of associations that 
Interface (GUI) supported by this system allows the LMS maintains. LMS was specifically and intentionally 
user to "point-and-shoot" by moving the cursor 15 to an designed to keep this information separate so as not to 
icon or specific location on the screen 16 and then press require the client applications to have to modify or 
one of the mouse buttons to perform a user command or corrupt their data in order to be an LMS participant, 
selection. 65 This increases the openness of the LMS system. 

FIG. 2 shows in block diagram form the components There are basically two types of links which may be 
of the personal computer shown in FIG. 1. The system established. The first, illustrated in FIG. 4A, is a urudi- 
unit 11 includes a system bus 21 to which the various rectional link. This is a marker to object link. In FIG. 
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4A, 41 and 42 represent windows in which various show, an audio show and the like, to provide an end 
applications may be running. For example, in window user with multiple choices to access information on a 
41, there may be displayed a text document generated particular topic. Typically, the presentation of the topic 
by a word processing program, an image generated by is authored by a first type of end user of the system, say 
a graphics program or a spreadsheet. A marker 43 may 5 an instructor, and is viewed by a second type of end 
be located at some point in the displayed document, user of the system, say a student. Thus, the presentation 
image or spreadsheet, and this marker 43 can be linked of the topic to the student may begin by displaying an 
to an object in window 42. The linked object may be in initial window on the screen 16 of the display device 14 
a text document, an image, a spreadsheet, audio, video, (see FIG. 1), and the student will typically have one or 
slide show or any other application. The link is unidi- 10 m0 re link markers from which to select. The presenta- 
rectional since selecting the marker 43 will cause the t ion then follows an arbitrary order depending on the 
linked object to be displayed in window 42, but there is particular selections of the student, 
no return to the marker 43. Using the example given above, when an end user is 

A bidirectional link is illustrated in FIG. 4B. This is a reading a hypermedia document about nutrition and 
marker to marker link rather than a marker to object 15 comes across a ^ mzT ktT, indicating that a Table of 
link. Thus, for example, a marker 43 in window 41 may Nutritional Values will be shown to the reader if the 
be linked to a marker 44 in window 42. Selecting lmk xs triggered (e.g., activated via a pointing 

marker 43 will cause marker 44 in a text document, d cv ice), and the reader activates the link marker, then 
image or spreadsheet in window 42 to be displayed. the Table is presented to the reader. If the reader had 
Note that a marker can Unk to a marker in the same 20 using the document in hardcopy form (e.g., a 
application. For example, marker 45 in, for example, a book) then the reader had to Mrch for ^ 

text document can be linked to another marker 46. As Tab]e usmg the index or ^ mt other cross .reference 
illustrated in FIG. 4B, the marker 46 may not be simul- scctjon of the documcnt) and perhaps find multiple 
taneously visible with marker 45, but by selecting references for the Table, only one of which was for the 
marker 45, that portion of the document in which 25 actua j Tab j e 

marker 46 is located is displayed Likewise, when To supp0r t this type of presenUtion, a web datebase 
marker 46 is selected, that portion of the document in ^ . $ ^ LMS 51 m m t0 uscr 

which marker 45 is located is displayed of markers, or the entry of keywords, and present- 

F G. 5 shows in block d "f ™ erS (i.e., applications, programs) are launched (started) 
the Link Manager Services (LMS) 51 to various clien 30 ^ £ £ mfonnation . The web 

apphcations 52. As wdl be described in more detol > graphically display the relation- 

hereinafter the LMS 51 ^^^^^^ ships between documents, links and markers within the 

^dividual client ^^J^^ * S 35 tSSS^Si 

^ ^ that 

issue a call to the LMS 51 and the LMS 51 generates LMS, with varying amounts of scope (e g., the enure 
the required menu or dialog box thereby assuring an web of apphcations or "zoom in Jo • ^ 
absolutely uniform and consistent EUI from client .p. 40 ments, and (2)^ls for we bdatab ^atamttd 
plication to client application. In addition, the LMS 51 development. The database 53 is typical 1> ^ °n t^ 
provides the EUI by which various of the client appli- har ^ disk drive 26 (FIG. 2) and he web viewer 54 
cations 52 may be launched. This will become clear Produces the output neensto display device 14 (FIG 
from the following discussion with reference to the »■ It should be understood, however, that the web 
various drawing figures, but it should be understood 45 viewer is not the general presentation space and/or 
that the LMS 51 is a vehicle for accessing data which device provided by the underlying operating system, 
may have been generated by any one of the client appli- devices or LMS. Moreover^ use is not required in 
cations and, when required, will automatically launch a order for LMS to be used. The web viewer is a general 
client application in order to access data which has been utility application which U neither necessary for the 
linked to a marker. 50 practice or understanding of the disclosed and claimed 

FIG. 5 introduces a new concept and that is the no- invention and, therefore, is not described in more detail, 
tion of a "web". The term "web" is used to refer to a The specific GUI environment in which the uiven- 
collection of document, link and link marker definitions. tion is practiced is a windowing environment. The basic 
The web represents all the information required by messaging set-up is common to most windowed sys- 
LMS to navigate the defined associations. The naviga- 55 terns, including OS/2 PM, Microsoft ® Windows and 
tion can take the end user from a link marker in one X-Windows. Basically, every window in the system has 
document to another application, to a document ren- what is called a window procedure associated with it. 
dered by a different application, to a margin note (au- When the operating system sends a message to a win- 
dio, text, etc.), or to another location in the same docu- dow, that message is routed to the window procedure 
ment The target application can be one that is partici- 60 associated with that window. A window procedure is 
pating in the use of LMS or one that is not even aware simply a piece of code provided by the application 
of LMS. In other words, the use of the web allows LMS which owns that window, and which knows how to 
to maintain all the necessary data about the associations deal with certain types of messages. The usual messages 
between documents without modifying the documents that are sent from the operating system to a window are 
themselves. 65 user input messages. Messages include things like button 

In one application, a web may be conveniently presses, window activation, and the like. The window 
thought of as a presenUtion system which utilizes sev- procedure of the window receiving the message can act 
era! client applications, such as a word processor, a slide on the message or not act on the message. If the window 
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procedure does not act on the message, there are certain message. The message would not fall into the category 
default procedures that might be called. of mouse message, menu command message or applica- 

In the present invention, LMS makes use of the win- tion specific message, and the application would there- 
dowing facility as well. In some places in the flow dia- fore not process the message and would call the LMS 
grams, arrows are shown going into the window proce- 5 processing procedure. The LMS processing procedure 
dure from both the operating system as user actions is aware of that message and will go ahead and return 
from LMS as notification. That means that LMS is also TRUE, "yes I am an LMS aware application", 
sending notification messages to the application's win- Having described the basic hardware and system 
dow procedure. configuration, the operation of the LMS will be de- 

Referring now to FIG. 6 of the drawings, there is 10 scribed by way of example. FIG. 7 shows a computer 
shown the logic of the client application window proce- display screen produced by a Bitmap Displayer pro- 
dure according to the invention. This shows a window gram. This program is a presenter (i.e., application) 
procedure for a typical LMS enabled application, other- which is rendering the GLOBE.BMP document (a 
wise known as client application. The user does some bitmap graphic). The GLOBE. BMP document contains 
input (e.g., presses a mouse button, selects a menu, 15 a link marker (whose text says, "More info-* 1 ') which 
presses a key or a combination of keys, etc.) at operation indicates the existence of associated information. When 
block 61, and the operating system sends that message clicked on with the mouse, the link associated with the 
to the client application's window procedure. When the link marker will be navigated and the user will be pres- 
client application's window procedure gets the mes- ented with the File Browser presenter rendering the 
sage, it tests the message in decision block 62 to see if 20 WORLD.TXT document (see FIG. 8). The 
the message is a command message (e.g., a menu com- WORLD.TXT document also contains a link marker 
mand message). If so, the application makes a further (whose text says, "See a picture-*-") which, if followed, 
test in decision block 63 to see if it is one of the menu would traverse to the GLOBE.BMP document, 
commands that it has defined; that is, is it one of the As mentioned, LMS also provides a consistent EUI 
menu commands that is pertinent to that application 25 by assuming the responsibility for generating menus, 
regardless of LMS? These commands include open a There are two types of menus; context menus (some- 
new file, cut, paste, and other commands that are partic- times referred to as pop-up menus) and pull-down 
ular to applications. If it is one of the menu options that menus. The former are menus that are displayed de- 
the application itself has defined, then the application pending on the context or location of the cursor within 
will just go ahead and process the command in function 30 the field of the display. FIGS. 9 and 10 show examples 
block 64 as if LMS did not exist. On the other hand, if of two types of context menus. In FIG. 9, the user has 
the command is not an application defined menu item, clicked the mouse button over the client application's 
but it is a menu command, then the application will call client or workspace area, near the top of the African 
the default LMS processing procedure in function continent. This context menu provides the user with 
block 65. This service is simply one function call, which 35 several options, including creating a marker at that 
is the LMS default processing procedure. Thus, if the location. In FIG. 10, the user has clicked on the link 
application does not understand the menu command, marker. The context menu displayed is similar but offers 
then it will call the LMS service. different options (due to the different context), allowing 

Returning to decision block 62, if the command is not the user to move or delete the marker, among other 
a menu command, then a test is made in decision blocks 40 things. 

66 and 67 to see if it is some other type of message Client applications need not explicitly instruct LMS 
specific to the application. For instance, some applica- to build context menus, and in some cases (e.g., when 
tions are interested in knowing if a mouse message came the mouse is over a link marker as in FIG. 10) need not 
in. And if it did, as determined in decision block 66, the even forward any messages to LMS. Context menus, 
application would process it in function block 68 if that 45 then, become almost a "free" feature of LMS, and pro- 
was the type of application that processes mouse mes- vide access to the identical functionality of the pull- 
sages. Some applications do not process these messages, down menu. 

some do not need to, and typically whether an applica- During client application initialization, the client 
tion processes that message or not, the application application calls LMS requesting that the hypermedia 
should call the default LMS procedure in function 50 pull-down menu be built. LMS will then dynamically 
block 69 so that LMS has a chance to look at that mes- build the menu so that the menu need not be defined in 
sage and to act on it accordingly. For instance, LMS client application code. All subsequent processing of 
might bring up a context menu. the menu (e.g., placing check marks next to menu items, 

If command is not a mouse message, then the applica- disabling menu items, selecting menu items, etc.) is han- 
tion determines in decision block 67 whether the mes- 55 died by LMS when LMS receives operating system 
sage is some other application specific message, and if messages which the client application is not interested 
so, the application calls whatever function it calls to in processing. 

handle that message in function block 71. Otherwise, as All operating system messages not processed by the 
with any message that the application docs not know client application are forwarded to LMS by the client 
how to process, the application will call the LMS de- 60 application using an LMS provided service. This in- 
fault processing procedure in function block 72. eludes menu messages. Based on the particular menu 

In addition to messages generated by user inputs, message, LMS decides what needs to be done, and does 
LMS sometimes sends its own messages to client appli- it For instance, if the message is that the hypermedia 
cations, as indicated in function block 73, expecting to menu is about to be shown, then LMS will adjust the 
receive the message itself. Thus, LMS in one window 65 menu's appearance, if necessary, (e.g., disable all inap- 
might send a message to another window in the system propriate menu options, etc.) based on the current state 
asking that window if it is aware of LMS, and the appli- of links and link markers, before showing it, or, if the 
cation in that other window would not understand the message was that "Create marker" was selected, LMS 
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will create a link marker for the end user without any message is a menu command, then LMS will go ahead 
additional work on the part of the client application. All and try to perform the appropriate action. For instance, 
applications using LMS will have the same hypermedia there are certain messages such as save markers and 
menus, and the menus will behave in the same fashion, links, password, and the like, that LMS will process. If 
thereby ensuring a consistent EUI. 5 the message is one that LMS will process as determined 

Examples are shown in FIGS. II to 15. More specifi- in decision blocks 85, 86 and 87, LMS notifies the client 
cally, FIG. 11 shows a pull-down menu when a mouse application of the forthcoming action in function block 
has been clicked on LINK in the action or command 88 and then, if the application does not object to LMS 
bar. performing the command as determined in decision 

Pull-down menus may be layered. For example, FIG. 10 block 89, LMS performs the function in function block 
12 shows a second pull-down menu when a mouse has 90, notifies the application in function block 91, and 
been clicked on MANAGE MARKERS in the first returns a "TRUE" message in function block 92. Thus, 
pull-down menu of FIG. 11, and FIG. 13 shows a third if the message is one of those commands that LMS will 
pull-down menu when a mouse has been clicked on process, LMS will perform the command, as discussed 
CREATE MARKER in the second pull-down menu of 15 in more detail hereinafter. Then LMS notifies the appli- 
HG. 12. A further example is shown in FIG. 14, which cation after it performs a command, and usually it 
shows a second pull-down window when a mouse has supplies the application at that point also with a handle 
been clicked on MANAGE LINKS in the pull-down to the object that it just acted on so that the application 
window of FIG. 11, and FIG. 15, which shows a third can do some post-processing. 

pull-down window when a mouse has been clicked on 20 If the message is a marker operation as determined in 
CREATE LINK in the second pull-down window of decision block 93, a further test is made in decision 
FIG. 14. block 94 to determine if the marker is in a selected state. 

FIG. 16 is a flow diagram showing the logic of the The marker must be in a selected state before a user can 
pull -down menu processing. In order to get all those modify it from the command pull-down menu (although 
different menu items that are in that menu, LMS will 25 this is not true of context menus). Typically, those items 
actually build that menu for the client application, which only act on objects which are not in a selected 
which also means that if in future releases of LMS addi- state are grayed out. For example, if there are no se- 
tional functionality is added, the client application will lected markers, then move marker would be grayed out, 
not have to release a new version to inherit the addi- and the user would not be allowed to select it. If there 
tional LMS features, since LMS builds that menu. The 30 are no markers selected, then modify marker would be 
way LMS builds the menu is that when the application disabled and the user would not be able to select that 
first starts up, it calls LMS, through an LMS API func- command. This is different from context menus in that 
tion call, and passes LMS a handle to its top level menu, context menus simply omit items that are not applicable, 
usually the action bar, as indicated at function block 75. In any case, LMS does provide code to double check to 
LMS then loads its pull-down menu definition which 35 make sure it is okay to do some work. Therefore, if the 
has been saved as a resource as part of its dynamic link menu command operates on a marker, it will first deter- 
library in function block 76. When LMS loads the re- mine whether or not there is at least one marker se- 
source, it will insert it, or attach it, into the client win- lected in a selected state and, if so, go ahead and do the 
dow's menu handle in function block 77. From then on, appropriate marker command; that is, modify marker, 
when that menu option is selected by the end user, they 40 create link, complete link, show markers, hide markers, 
will see all the LMS menu items in that menu. This etc. as determined by decision blocks 95, 96, 97, 98, 99, 
procedure occurs at initialization time. and 100. Create link and complete link are considered 

The rest of the flow diagram of FIG. 16 illustrates marker operations because they create a link emanating 
how the actual pull-down menus are processed. Keep in from a marker or complete a link to a marker. Once 
mind that in LMS there are two types of menus. The 45 those commands are completed, the application is noti- 
pull-down menus are the menus that are displayed when fled that LMS performed a command and return true, 
the user selects the link from the action bar, while con- Turning now to FIG. 17, there is shown a flow dia- 
text menus are displayed in response to mouse clicks on gram which illustrates the logic of the context menu 
the client window. Context menus are afforded similar processing procedure 101. The process begins by first 
options, but they are more specific to the object that the 50 determining in decision blocks 102 and 103 what type of 
user has clicked on. Thus, what happens in the process- context menu LMS is. supposed to display. The test in 
ing for these two types of menus is different. decision block 102 determines whether a doc. context 

When a user action comes in, as indicated at function menu is to be displayed, and the test in decision block 
block 78, it goes to the application's window procedure, 103 determines whether a marker context menu is to be 
represented by function block 79. At that point, the 55 displayed. If LMS is supposed to display a doc. context 
application window procedure may determine that this menu, the resource definition of that menu is loaded in 
is not a menu command that it knows (i.e„ defined in the function block 104, and if LMS is supposed to display a 
application code), so it passes the message to the LMS marker context menu, the resource for the marker menu 
processing procedure (see FIG. 6). LMS determines in is loaded in function block 105. If neither a doc. context 
decision block 81 whether the message requires a menu 60 menu nor a marker context menu, an error message is 
to be shown. If so, in function block 82 LMS might returned in function block 106. 
enable some menu items that are applicable, disable ones Once LMS has loaded the menu, a hidden window is 
that are not applicable, and/or check some items. Oth- created in function block 107 which is actually going to 
erwise, a test is made in decision block 83 to determine own the menu that was just loaded. Then, in function 
if the message is a menu command message. If not, the 65 block 108, the loaded menu is added to the new window 
••Non-Menu Command Message Processor" is called in and, in function block 109, the window is told to show 
function block 84. This procedure is described in more the menu. It should be understood that items in the 
detail hereinbelow with reference to FIG. 18. If the menu will be removed, based on the state of the object, 
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similar to when items are enabled and disabled from the mouse button three is pressed. If so, context menu pro- 
link pull-down menu. At this point, LMS waits for a cessing is returned in function block 119 and, in decision 
user selection in function block 110. In decision block block 121, a test is made to see if a command was en- 

111, a determination is made as to whether or not the tered by the user or if the user selected cancel. If a 
user actually canceled the menu or selected an item 5 command was selected, then LMS does the basic pull- 
from the menu. If a menu item was actually selected, the down menu processing, as indicated in function block 
command ID is returned, as indicated in function block 122 and illustrated in FIGS. 16 and 17. Essentially, 

112. Otherwise, a false is returned in function block 113. LMS executes the command with a notification to the 
Now that the cases when LMS gets a user command client application, as described above. Remember that 

because menus have been selected have been discussed, 10 in the notation of the flow diagrams, every time "do 
what about other non-menu command processing? A 'menu pull-down processing"' appears in a flow dia- 
generally available feature of most windowing systems gram, the process does not go to the top of the flow 
is that of messages. Messages may be sent to an applica- diagram shown in FIG. 16 for menu pull-down proccss- 
tion from the operating system, another application, ing but, rather, enters at function block 88 of FIG. 16. 
itself, or services operating on behalf of the application, 15 Returning to decision block 118, if the mouse three 
These messages are notifications to the application of button is not pressed, then a further test is made in 
requests, responses to requests, actions performed, etc. decision block 123 to determine if the message is SHIFT 

Similarly, LMS uses this mechanism to allow client key plus mouse button one. This is a way of creating a 
applications to optionally be aware of, qualify, limit, link and a marker. If so, LMS does that processing in 
modify, or prevent actions that LMS is about to take. 20 function block 124. If not, a test is made in decision 
Additionally, LMS informs client applications via mes- block 125 to determine if it is a command message. If so, 
sages after some actions have been taken. Both the "be- a determination is made in decision block 146 as to what 
fore" as well as the "after" messages are sent regardless sort of command the command is. That is, is the com- 
of whether the actions represented by the messages mand one that LMS has defined as a command? If it is, 
were initiated by the end user using the EUI, or by 25 a message is passed to the application in function block 
another client application, or by the client application 127. That message will again filter back down to LMS 
itself. Generally, the client application is free to ignore because the application will not want to process it, and 
(pass through for default processing) these messages then LMS will do its LMS command processing. If the 
and will obtain the default (LMS) processing for them. message is not a command message, then LMS just 
But the opportunity to do otherwise is available. 30 discards it in function block 128 if the message is not one 

For example, when LMS has been requested to show that LMS understands, 
a pull-down or context menu, LMS sends the client Referring back to decision block 125, if not a corn- 
application a message notifying it of same before any mand message, then a test is made in decision block 129 
action is taken regarding the menu. The client applica- to determine if the message is an LMS message; that is, 
tion might want to disable/remove some item from the 35 is this an LMS specific message that LMS uses to com- 
LMS menu before the menu is actually displayed. Simi- municate with itself? LMS running on behalf of differ- 
larly, when an LMS menu item is requested (e.g., to ent processes that are using LMS might send these 
create a link marker), or the end user "clicks" on a link messages back and forth to communicate with each 
marker thereby requesting that LMS navigate/follow other without involving the client application. If it is an 
to the other end of one or more of the link marker's 40 LMS message, one example of that type of message 
"other ends", then a message is sent to that client appli- might be a query as to whether the application is LMS 
cation advising it of same. aware, as indicated by decision block 131. If not, when 

LMS provides a rich API by which client applica- that other window gets this message, it will not have 
tions may optionally exert control over the behavior any LMS processing procedure to call. Therefore, that 
and data of the LMS hypermedia system. In fact, in 45 window would just return false, indicating that it does 
terms of functionality and capability, the LMS API is a not understand the message. But if this message goes to 
significant superset of the LMS EUI, thus providing an application that is LMS aware, it will return true, as 
client applications with powerful capabilities and possi- indicated by function block 132. The message will get 
bilities. More typically however, in order for a client filtered down to the LMS processing procedure, as 
application to be a significant participant as a hy* 50 described before. If, in decision block 129, the message 
permedia participant, it only needs to make minimal use is not an LMS message, the message is discarded in 
of the LMS API. function block 133. 

Reference is made to FIG. 18 which is a flow dia- The end user interacts with objects on their screen by 
gram of the logic for the procedure for non-menu com- using the mouse. LMS manages mouse interactions with 
mand message processing. Again, the user does some 55 LMS objects (e.g., documents and link markers). LMS 
input at function block 115, and the operating system manages mouse actions in a number of ways, 
gives a message to the client application window proce- Client applications typically forward mouse messages 
dure in function block 116. The window procedure will to LMS. When LMS receives these mouse messages, it 
forward the message onto LMS in function block 117, determines if some hypermedia-specific action needs to 
as described previously. 60 be taken. Using this mechanism, LMS is able to control 

This processing procedure assumes that LMS has the mouse when it is over the client application's "client 
gotten past the testing to see if the message is a menu window" (main application workspace). When a client 
command. The other messages besides menu messages application first displays a document, it notifies LMS of 
include mouse messages, messages from other windows this, informing LMS of the name of document and the 
that are sent to LMS from LMS itself (e.g., messages 65 handle of the window in which the document is dis- 
such as asking another application if it is an LMS aware played. LMS will then obtain, from the LMS database, 
application), etc. The non-message command message all LMS objects associated with the document. LMS 
processor first checks in decision block 118 to see if now has enough information to process mouse messages 
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that occur in the client application's client area. This tion uses LMS services. If the target window of this 

allows LMS to display context menus (see FIG. 9) over process is an application that uses LMS services, a link 

the client application's client window. When mouse marker will automatically be created for that applica- 

messages get forwarded to LMS, LMS determines the tion at location of the mouse pointer, and a link will be 

state of the hypermedia objects (links, link markers, 5 established with the starting point of the operation. If 

etc.) in the document, and can determine what types of the response to the message is that this application does 

items should be in the context menu (e.g., "Save mark- not use LMS services, then a link will be established to 

ers", "Hide markers", etc.). This facility is also used for that application, but no marker will be placed in it 

the operation of making "quick" links, whereby the user (LMS refers to these types of applications as "un- 

can simply mouse click over two points (either within 10 aware"). 

the same document, or different documents and present- The end user may create link markers within the 

ers) and have two link markers (one at each point) auto- client application window, delete them, size them, 

matically created as well as the link between them. change their text, and change their appearance style. 

Typically, this is accomplished by the end user individ- With the exception of marker creation and deletion 

ually creating two link markers, and then creating the 15 (which require the forwarded messages, as described 

link. The above functionality is all accomplished with- above), this can all be accomplished without any client 

out the aid or knowledge of the client application, and application participation. Since LMS "owns" the link 

will be consistent for all client applications which utilize markers (as described above and described in more 

LMS services. detail below with reference to FIG. 20), LMS controls 

Since LMS link markers receive messages directly 20 the painting and positioning of the link marker win- 

from the operating system, and the class of windows dows. Link markers may be made to invert the client 

known to the operating system as "LinkMarker" is application data below them, which appears to the user 

"owned" by LMS (i.e., the operating system invokes as highlighting, however no processing is required of 

LMS code directly when a window of this type gets a the client application to achieve the inverted area, 

message), mouse management over link marker win- 25 Referring next to FIG. 19, there is shown a flow 

dows is accomplished without the need for the client diagram of the logic of the create marker procedure of 

application to "forward" messages to LMS. LMS. The process starts with a create command in 

When a link marker receives a message (from the function block 135. This means that one way or another, 

operating system) that the mouse is over it, LMS will the create marker command has been received, whether 

change the mouse pointer appearance to indicate the 30 from the link pull-down menu or from the context menu 

presence of a link marker to the end user (this is espe- displayed when the user clicks on the client workspace 

cially useful since markers may be "invisible", i.e., the in the client window of the application but not on a 

user may interact with them, but cannot see them). marker. In the case of clicking on the client workspace, 

Additionally, this allows for LMS to handle many other the action may be considered as clicking on a document, 

types of mouse activities over link markers, such as 35 so the context menu is called a document context menu, 

"grabbing" a marker with the mouse and repositioning or simply a "doc. context menu". In any case, it is as- 

and/or resizing the link marker, displaying context sumed in the flow diagram of FIG. 19 that a create 

menus (see FIG. 9) for link markers, and viewing the command has come in from one of those sources, 

link marker's associated links. The first thing that is done is that LMS captures the 

LMS also has the ability to manage the mouse when 40 mouse in function block 136. That is a windowing term 

the mouse is over windows which do not use LMS meaning that control of the mouse pointer is obtained, 

services. One situation where this occurs is when end The mouse pointer is changed in function block 137 to 

users create link markers and links using "quick" link a different pointer shape to indicate that LMS is in the 

which is a fast path method for establishing links. In this process of marker creation. This shape is a tracking 

situation, the user simply presses a mouse button and 45 rectangle that the user moves around the screen indicat- 

keyboard key while the mouse is over some part of a ing where they want to place the marker, 

client application's document, and then "drags" the Next, the process waits for operating system mes- 

mouse to another point (either in the same document, or sages in function block 138. This is done by inserting a 

another document/presenter) and releases the mouse new message processing loop so that the application can 

button (if at any time during this operation the mouse is 50 continue running, but LMS filters all messages before 

over an area which is not a valid link termination point, passing them to the application. Thus, function block 

the mouse pointer appearance will change to indicate 138 is a little loop called a get-message loop which 

this to the end user). This procedure allows link markers keeps looking for messages. Normally it is the applica- 

and a link to be established between the two points, all tion itself that does that, but LMS exercises very tight 

in one step. The only client application participation 55 control here. Every time' a message comes in, LMS 

required during this processing is the forwarding of looks at it and determines in decision block 139 whether 

messages to LMS, as described above. this is a message that terminates this capturing of the 

LMS implements this functionality by using operat- mouse. If not, the message is dispatched to the client 

ing system services to obtain exclusive use of the mouse application in function block 141; otherwise, the mouse 

(i.e., receiving all mouse messages, regardless of which 60 capture is ended in function block 142. A test is then 

window the mouse is over). When the mouse button is made in decision block 143 to determine whether the 

released (to complete the operation), LMS queries the user canceled out of the marker creation process or did 

system to determine which window, if any, the mouse is they truly want to continue. If the user canceled out, the 

over. A message is then sent to that window to deter- process is canceled in function block 144; otherwise, if 

mine if it is an application which uses LMS services. If 65 the user wanted to continue, then a new "marker" is 

the window receiving the message uses LMS services, it created in function block 145. (The marker is an object 

need not (and will not) process this message, but will in the context which that term is used in object-oriented 

forward it to LMS which will respond that this applica- programming languages.) Then the actual marker ob- 
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ject gets a new identification (ID) from the database in using the mouse, moves the marker in function block 
function block 14*, and a marker window is created in 166 or sizes the marker in function block 167. 
function block 147. This marker window is a visible Returning to decision block 158, if the message is not 
manifestation of the marker, and whenever a window is a mouse click, it is tested in decision block 168 to deter- 
created in a windowing system, a window procedure is 5 mine if it is a paint message. If so, the marker closes its 
assigned to be associated with that window, as dis- window to be repainted in function block 169. 
cussed above. The window procedure for the marker Referring next to FIG. 21, the flow diagram shows 
window function resides in the LMS dynamic link li- the logic of the window painting processing. The oper- 
brary. That way, every time the marker is clicked on or ating system sends LMS a message in function block 
any input comes to the marker, the link manager code is 10 171, as in the other processes described. The message 
executed, thereby effectively eliminating any client this time comes directly into the marker window proce- 
application interaction. After the marker window has dure 172 because markers get messages without having 
been created, it is then shown in function block 148. to go through the client application first. The marker 
Referring now to FIG. 20, the logic of the marker window determines in decision block 173 whether the 
window procedure is shown. In the context of this 15 message is a paint message. If it is a paint message, that 
invention, a link marker may be conveniently thought is, the operating system is saying that the window must 
of as a window within an application window, and in be redrawn, the marker determines in decision block 
fact that is what it is. The marker window procedure is 174, by looking at the database, what the marker style is. 
similar to the client application window procedure or There are two styles that are not transparent (i.e, you 
any window procedure, and the code for the marker 20 cannot see through them); one is called black and white, 
window procedure resides in LMS. Messages are input and is two dimensional, and the other is called push 
by the user in function block 151 via the operating sys- button, and which has a three dimensional appearance 
tern in function block 152 to the marker window proce- providing a visual depression movement when pressed, 
dure in 153. When the marker window gets messages, Any of the other styles, are transparent and are repre- 
the marker window procedure checks for user indica- 25 sented in a screen print as a video inverse or high-light 
tions of things it has to do. For instance, a test is made frame as illustrated, for example, in FIG. 22. 
in decision block 154 to determine whether button three If not a see-through type marker (i.e., a push button 
down! If mouse button three is down, then the marker or a black and white), then the marker is painted in 
will display the marker context menu in function block function block 175. But if it is a transparent marker 
155 because, in the preferred embodiment of LMS, that 30 style, then the marker is hidden in function block 176; in 
is how a user brings up a context menu, by pressing other words, the whole marker window is removed 
buttons over a window. The context menu processor from the screen. When the marker window is removed 
will return whether or not a command was actually from the screen, the parent window below is told to 
selected from the context menu, as indicated in decision repaint itself in function block 177. This assures that 
block 156. If a command was selected, then LMS essen- 35 everything, all the data in the parent window, is current 
tially goes into the pull-down menu processing, as gen- and up to date. As soon as that is done, the marker is 
erally indicated , in function block 157 and illustrated in reshown in function block 178, but the parent window 
FIG. 16, starting at function block 88, and in FIG. 17. is not repainted unless it is desired to paint the border or 
That is, LMS gives a notification message to the client do an inverse. 

application before actually 1 executing the command in 40 Under Microsoft ® Windows and OS/2 PM, there 
case the client application wants to prevent LMS from are no bits reserved on the pallet for transparency, so a 
executing the command. LMS also sends the client window can not be made that a user can see through 
application a message after executing the command. and that would be updated correctly and properly at 
Anytime LMS internally is about to execute a com- 15 all times, Windows and OS/2 Presentation Man- 
mand, LMS always notifies the client application first 45 ager windows are opaque. Typically, when a window is 
with a special LMS message. And any time after LMS created by an application, the window comes up on the 
has performed a command, LMS always notifies the screen; i.e., the operating system tells it to paint itself 
client application with a message saying LMS has per- and it paints itself. Of course, in painting over any win- 
formed the command. dow, as by grabbing one window and putting it on top 

What if the user input is just a regular mouse click as 50 of another, what happens is that the operating system 
determined in decision block 158? If it is, a further test does not actually draw* into the window; rather, the 
is made in decision block 159 to determine if the mes- operating system fills the window with a white back- 
sage is a double click on mouse button one. If so, then ground, text or whatever. This is illustrated, for exam- 
the follow-link operation is performed in function block pie, in FIG. 23 which shows many different types of 
161. The C++ "marker object" knows all the links that 55 windows, scrollbars, icons, pushbuttons, etc. The oper- 
are associated with it and all the information about ends ating system creates the window by reserving an area of 
of links, and all this information is stored in the database the screen and, when the mouse is clicked there, the 
so LMS is able to do the follow link. On the other hand, operating system sends that window procedure mes- 
if the message is a double-click on mouse button two, as sages, but the user is still able to see through the win- 
determined in decision block 162, LMS will put up a 60 dow to the window below it So what appears on the 
dialogue box in function block 163 showing the user all surface to an implementation of transparent windows is 
the links that come out of the marker. actually something as simple as a window not painting 

If the mouse click is not any of those mouse click itself, 
messages, then LMS checks to see if a control key was Unfortunately, in practice, it is not quite that easy. If 
pressed at the same time the mouse button was down, as 65 every time the operating system tells this new window 
indicated in decision blocks 164 and 165. In that case, that has been created to paint itself, one possibility is for 
LMS does some direct manipulation work. Direct ma- the window to never paint itself, in order to be transpar- 
nipulation means that the user presses a control key and, ent. However, it will not really be transparent. All that 
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happens is that the bits on that area of the screen will the user to enter a keyword for purposes of a hy- 

not be painted. So if another window is brought on top pennedia database search. 

of the "transparent" window and then moved off, the The client application need not call any LMS services 

window that the "transparent" window is sitting on top in order to display or manage the dialog boxes; LMS 

of will repaint itself except in the areas where the 5 automatically provides this support. This ensures that 

"transparent" window is because windows never paint all applications using LMS services will provide a con* 

oveT other windows. And the "transparent" window is sistent set of hypermedia dialog boxes, across client 

not going to paint itself. The bits that were on the screen applications. 

will be the bits from the third window that were on top LMS contains the definitions (i.e., appearance/behav- 

of both the lt transparent" window and the window it 10 iors ) of dialog boxes. When the end user requests a 

sits on, so the screen is going to be incorrectly pres- hypermedia service (typically using menus), LMS will 

cnted. begin executing the request. If during this execution it is 

The solution to this problem is contained in the win- determined that dialog boxes need to be displayed (e.g., 

dow paint processing procedure shown in FIG. 21. more formation is needed), LMS will display them. 

Specifically, when that other third window is brought 15 Smcc of the hypermedia dialog boxes are concerned 

on top of our transparent window and then moved off, with LMS objects (e.g., links, link markers, etc.), LMS 

the operating system sends the transparent window a » 10 * Pply . cnd ™? s \? object 

paint message. Rather than just totally not painting, w *° ut «»pmtion of the client application 

what the window docs is to recognize that the bits on . 21 15 a flow diagram of the logic of the dialogue 

this part of the screen are from that third window and, 20 management. For each command that the LMS 

since that third window has moved away (as indicated command processor 181 performs, such as create mark- 

by the receipt of the paint message), the transparent «• ^ Imks ' "S** * m f the llk< \ a i C$t " 

. , *: f 4 • j Jl .u * v £ made in decision block 182 to determine whether a 

window must cause what is underneath to be shown. ... , . , „ T wc 

— . . . , u *v * * ■ a X. A- !<■ ♦ dialogue box is needed. If the answer is yes, then LMS 

This is done by the transparent window hiding tself at 25 * bQx function ^ m ^ 

function block 176 » FIG. 21. There are functions in * ^ ^ ^ ^ LMS resources just 

the operating system to do that. The parent window ^ * ^ w ^ stQred ^ ^ ^ ^ 

will then get a paint message from the operating system ^ ^ user mlerface ^ stQred ^ LMS? 

which the transparent window will teel the parent win- which mm u is ^ that if a new ver$ion of thc 

dow to act on immediately. At this point, the parent M LM$ - $ introduced) there win be a ncw user 

window will paint itself in function block 177. Windows that t0 lhe end user M part of thc client applica . 

will never paint over another window that is visible but tion without any rewrite of cUent application code . 

will paint other screen areas if a window is not visible In ^ ^ the dia ] ogue ^ is displayed according 

(i.e., hidden) in that screen area. So the procedure is to to what ob j ect LMS is wor king on; whether it is a 

hide a window and tell the parent window to paint itself 35 marker or a docurnent or a link, etc. If the dialogue box 

in this particular area where the transparent window docs modi f y ob j ects based on user interaction with it, as 

was. In this way, the screen is all refreshed, up jo date determined in decision block 184, then a message is sent 

and current. t0 tne application in function block 185 telling the appli- 

Now, the transparent window must be shown again. ^Moti that LMS is about to change something, at which 

When the transparent window is shown again, the oper- 40 the application responds in message block 186 

ating system recognizes this and directs the window to whether it is okay to continue. If the application says it 

paint itself, but the transparent window will not paint is okay to continue, then LMS processes the command 

itselfso that the end user can look through the transpar- m function block 187 and notifies the application in 

ent window to the data below This all happens instanta- function block 188, as before. 

neously and effectively produces transparent windows 45 . Returning to decision block 184, if the dialog box is 

on the PM of OS/2. Again, transparent windows may not going to modify an object, then LMS does not even 

do some painting if that is desired, like inverting the bits bother asking the application if it should do this or not. 

that are in thc rectangular region of the screen occupied Instead, LMS processes the command in function block 

by the transparent window to produce an inverse video 199. 

highlighting or draw a wire frame on the boundaries of 50 Finally, if the dialogue box is not used as determined 
the window as shown in FIG. 22. In FIG. 22, which is by the test in decision block 182, a further test is made 
a screen print that shows an inverse video highlighted m decision block 191 to determine if direct manipulation 
text, on the screen 14 (FIG. 1) it is not really high- j s needed. Direct manipulation, again, is grabbing mark- 
lighted text; it is actually a transparent window there. ers with a mouse, not selecting menu items; that is, just 
In addition to menus, another method of interaction 55 using the keyboard and the mouse to select things and 
between an end user and an application is the use of grab them and do things to them, make links, etc., with- 
dialog boxes. Dialog boxes gather information needed out any menus involved. If some sort of direct manipu- 
for particular tasks from the end user. LMS provides lation is needed, then LMS sends a message to the appli- 
and manages all dialog boxes necessary for a client cation in function block 192. For instance, if the direct 
application to provide full hypermedia support. FIGS. 60 manipulation is to move a marker which, by the way is 
24, 25 and 26 give examples of some of the dialog boxes an item that a user could select from a pull -down menu, 
provided by LMS. More specifically, FIG. 24 shows an LMS sends the application a message saying that it is 
example of the dialog box used to prompt the end user about to move the marker just as if the user had selected 
to specify the style of a link marker. FIG. 25 shows an that function from a pull-down menu, so that the client 
example of the dialog box used to prompt the end user 65 application does not have to be sensitive to the method 
to select a link for purposes of management; i.e., dis- the user is using to perform these activities. As before, 
playing the link marker abstract, follow the link, etc. LMS waits for the application to respond whether or 
FIG. 26 shows an example of the dialog box to prompt not it should proceed. If the application responds that it 
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is okay to proceed, LMS processes the command in 
function block 187 and then, as always, after processing 
the command, notifies the application in function block 
188. 

As is true of other areas of the LMS supplied EUI, 
although the client application is not required to pro- 
vide any hypermedia support, they may modify, en- 
hance, or prevent the displaying of the LMS supplied 
dialog boxes. Additionally, services are provided for 
client applications to display LMS dialog boxes at times 10 i 
of their choosing, rather than only when LMS finds it 
necessary. 

All information needed to support links between 
documents is maintained by LMS in a separate database 
known as a web (see FIG. 5). The files containing the 15 
client application's data need not be modified in order 
for that application to utilize LMS services; rather, a 
conceptually parallel "view" or "overlay" of all of the 
hypermedia objects is stored in the web database. The 
client application need not be concerned with the for- 20 
mat of this database nor with accessing the database; 
these concerns are handled entirely by LMS. This data- 
base may be used in a single-user workstation environ- 
ment, or a multiple workstation/uscr/process (e.g., 
network) environment permitting shared database ac- 25 
cess, including update. The LMS hypermedia objects 
thus remain persistent (in the database) after the client 
application has ended, and they will be made available 
again when the client application is again used to render 
its document(s). This design, which offloads much work 30 
from the client application, is described below. 

The hypermedia objects are documents, presenters, 
link markers, and links. LMS will save all new and 
modified hypermedia objects into the database, and 
remove all hypermedia objects from the database for 35 
which deletion has been requested, when requested to 
do so (either by the end user or the client application), 
as well as when the client application is closed (unless 
requested to not do so by either the end user or the 
client application). 40 

When a client application is rendering its data, object 
creation can be manifested in either or both of two 
ways: 

Hypermedia object previously existed in the data- 
base: When the client application identifies itself and its 45 
document to LMS, LMS automatically loads the rele- 
vant hypermedia object data from the database and 
displays the link markers appropriate for the portion of 
the document currently being displayed by the client 
application. SO 

Hypermedia object does not exist in the database: 
Presenter objects, which contain LMS data about the 
client application (e.g., its name), are automatically 
created by LMS whenever a client application first 
becomes known to LMS (i.e., when the client applica- 55 
tion "checks in" with LMS via the LMS API). The 
same is true for document objects. LMS creates link 
marker and link objects whenever requested to do so by 
either the end user (using the LMS EUI), and/or the 
client application (using the LMS API). Examples of 60 
the latter (LMS API) case might be heuristic or other 
artificial intelligence client applications; or utility pro- 
grams written to dynamically (i.e„ without end user 
interaction) create documents, link markers, and link 
objects for previously existing (perhaps large) corpora 65 
of machine readable information, the format, content, 
and semantic associations of which are known or dis- 
coverable by the programs such that a highly useful, 



perhaps non-lineal, web database of hypermedia associ- 
ations would be obtained (e.g., machine maintenance 
information, encyclopedias, medical information, per- 
sonnel skills information, education courses which 
would permit structured learning and/or virtually peri- 
patetic discovery, sales/catalogue information, a dictio- 
nary, etc.). 

FIGS. 28 and 29 are flow diagrams pertaining to 
LMS database maintenance. The procedure illustrated 
in FIG. 29 is calied from the procedure in FIG. 28. The 
database maintenance procedures are invoked when- 
ever the user of the hypermedia system creates, changes 
or deletes a document, link marker or link. In FIGS. 28 
and 29, references to lock and unlock when used in the 
context of database objects is intended to describe the 
scope of their availability to others. Lock means to 
obtain exclusive use, and unlock means to release exclu- 
sive use and thereby make available for others. There- 
fore, if one process locks an LMS document database 
object, then no other process can gain access to that 
object in the database until the object is unlocked. If a 
process locks the (entire) LMS database, then no other 
process can subsequently gain access to any object in 
the database until the database is unlocked. 

Referring first to FIG. 28, the LMS database update 
procedure begins by testing in decision block 201 to 
determine if the document which is the subject of the 
update exists in the database. If it does, the document is 
locked in the database in function block 202, otherwise, 
the database is locked in function block 203, but in 
either case, a further test is made in decision block 204 
to determine if the document is to be deleted. If so, the 
process enters a first loop to identify and, then remove 
the link markers belonging to the document. The loop 
begins with decision block 205 where a test is made to 
determine if this is the first or if there is another link 
marker belonging to this document. If so, the link 
marker is flagged for deletion in function block 206 and, 
then in procedure 207, the link marker and its links are 
removed from the database. This is done by calling the 
link marker and link database update procedure de- 
scribed in more detail with reference to FIG. 29 below. 
When a return is made from this procedure, the process 
loops back to decision block 205. 

If the test in decision block 205 indicates that there 
are no link markers or that all link markers have been 
flagged, the document is deleted from the database in 
function block 208. Then a test is made in decision block 
209 to determine if the document previously existed in 
the database. If so, the document lock is destroyed in 
the database in function block 210 before the procedure 
ends; otherwise, the database is first unlocked in func- 
tion block 211 before the procedure ends. 

Returning to decision block 204, assuming that the 
document is not to be deleted, a second loop is entered 
to identify link markers belonging to the document and 
then perform the update required. This loop begins with 
decision block 212 where a test is made to determine if 
this is the first or if there is another link marker belong- 
ing to this document. If so, a further test is made in 
decision block 213 to determine if the link marker is 
new, changed or deleted. If so, the procedure 214 is 
called to update the link marker and its links in the 
database. Procedure 214 is the same as procedure 207 
and, again, is described in more detail below with refer- 
ence to FIG. 29. When a return is made from procedure 
214 or if the link marker is not new, changed or deleted 
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m decision block 213, the process loops back to decision in function block 243. In either case, a further test is 

block 212. made in decision block 244 to determine if the link 

When all the link markers have been identified and marker previously existed in the database. If so, the link 

updated, the loop exists to decision bJock 215 where a marker is unlocked in the database in function block 245 

test is made to determine if the document is new or 5 before the procedure ends; otherwise, the database is 

changed. If so, the document object data is written into unlocked in function block 233 before the procedure 

the database in function block 216. In either case, a test ends. 

is next made in decision block 217 to determine if the While LMS provides a mechanism for off-loading 
document previously existed in the database. If so, the work from client applications, it is not desirable to re- 
document is unlocked in the database in function block 10 strict the client application. Sometimes when work is 
21S before the procedure ends; otherwise, the database off-loaded, the application can actually be restricted in 
is unlocked in function block 211 before the procedure its functionality. That is why LMS always sends notifi- 
ends. cation messages before it acts on commands. 

Turning next to FIG. 29, when the link marker and The client application is provided a way to store 

link database update procedure is called at procedure 15 information of its own liking with certain LMS objects, 

207 or 214 in FIG. 28, a test is first made in decision such as markers and links in particular. For instance, if 

block 221 to determine if the link marker exists in the a text editor application has enabled itself with link 

database. If so, the link marker is locked in the database manager services and it wants to know with what line 

in function block 222; otherwise, the database is locked number in its file the marker is associated, LMS does 

in function block 223. In either case, a test is next made 20 not understand client application data, so LMS does not 

in decision block 224 to determine if the link marker is know what a line is. To solve this problem, an area is 

to be deleted. If so, the procedure enters a first loop to provided in each LMS object, specifically markers and 

identify the links attached to the link marker and then to links, called user data, and APIs are provided to access 

delete those links. The loop begins with decision block this area of data. Basically, this is an area LMS does not 

225 where a test is made to determine if this is the first 25 understand the data stored there. It is an area where 

or if there is another link attached to the link marker. If applications can store data. LMS does not look at the 

so, the link's other-end link marker is locked in the data since it is raw binary data and the application can 

database in function block 226. Then, the other-end link store whatever it likes there. For instance, if an applica- 

marker is read from the database, the link is detached tion knows a marker belongs on line 5, then the applica- 

frorri it, and the other-end link marker is rewritten in the 30 tion can set some structure in the user data, or just one 

database in function block 227. The link's other-end link integer if it wants, saying this marker goes on line 5. 

marker is unlocked in the database in function block Now, LMS simply stores data away in the web data 

228, and the link is then deleted from the database in base with that particular marker object. Now, next time 

function block 229 before the process loops back to that editor shows that document and tells LMS to load 

decision block 225. 35 up all the markers and links, LMS will go through each 

When all links have been identified, the loop exits to marker, enumerating the markers using the functions 
function block 230 where the link marker is deleted provided by LMS and, as it enumerates, for each 
from the database. Next, a test is made in decision block marker it will identify the user data associated with this 
231 to determine if the link marker previously existed in marker. In the example given, that is the same user data 
the database. If so, the link marker lock is destroyed in 40 that the application stored, and LMS will simply pro- 
function block 232 before the process ends; otherwise, vide the data'that the application had stored. While 
the database h first unlocked in function block 233 be- LMS will not know what the data means, the applica- 
fore the process ends. tion will recognize it as meaning that this marker goes 

Returning to decision block 224, if the link marker is on line 5. At that point, the application can through the 
not to be deleted, the process enters a second loop to 45 API to reposition the marker or do whatever the appli- 

identify the links attached to the link marker and per- cation wants with it. 

form the required update. This loop begins with deci- The same is true for links. Links have the user data 

sion block 234 where a test is made to determine if this which behaves exactly the same as marker user data. An 

is the first or if there is another link attached to the link example usage of link user data might be the case where 
marker. If so, a further test is made in decision block 235 50 every time a link is established, the application wants to 

to determine if the link is new, changed or deleted. If so, keep information specific about what its state was when 

a test is made in decision block 236 to determine if the that link was created; e.g., whether an application has 

link is to be deleted. If so, the link's other-end link the ability to have or not have a title bar. What the 

marker is locked in the database in function block 237. application may want to do is to store that link user data 
Then the other-end link marker is read from the data- 55 (i.e., the fact that it does not have a title bar when the 

base, the link is detached from it, and the other-end link link was completed). At another time if it does have a 

markeT is rewritten in the database in function block title bar, it might store in that link. Then when that link 

238. The link's other-end link marker is unlocked in the is followed and the application comes up and loads its 

database in function block 239, and the link is deleted document, the application checks the user data in this 
from the database in function block 240 before the pro- 60 link. The user data informs the application that when 

cedure loops back to decision block 234. If the link is this link was created, the application did not have a title 

not to be deleted but it is new or changed, the link bar, so the application hides its title bar, but when the 

object data is written to the database in function block other link is found, the application will find that the user 

241 before the process loops back to decision block 234. data here says that it did have a title bar, so a title bar is 

When all the links have been identified and updated, 65 displayed, 

the loop exists to decision block 242 where a test is LMS does not understand the user data; it's like a 

made to determine if a link marker is new or changed. If little note pad that applications can keep with each link 

so, the link marker object data is written to the database and each marker. Additionally, LMS has something 
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called the user key with both links and markers which defined to be summary text information about the infor- 
are ways for applications to quickly sort through and mation that can be found at the location of the owning 
filing a particular marker or particular link. It is a key, link marker. Thus, when LMS presents a list of candi- 
so if an application always wanted to access one partic- date target link markers to the user (either as a result of 
ular marker item but many markers were associated 5 the user "clicking" on a link marker with more than one 
with a document, perhaps thousands, the application link emanating from it, or as the result of performing a 
could assign the marker a particular user key which is a link marker abstract search, each candidate target link 
long extra value. Most LMS functions take the user key marker will be represented in the list by one of the 
as a parameter, so if a user wanted to retrieve the first following: (1) the target's short abstract text, but if none 
marker, LMS would just return the first marker that we 10 exists then (2) the target's parent document name, but if 
find out of the whole set of markers. But if the user none exists then (3) the target's presenter name. There- 
wanted to retrieve the first marker with the user key of fore, having at least short abstract data for a link marker 
10, then LMS would do the searching through all the can be useful for providing meaningful distinctions for 
markers and determine which marker has a user key of the end user when displaying a list of candidate naviga- 
10. IS tion targets, as well as for use in searching. The link 
LMS provides for the deletion of hypermedia objects marker abstract object, if it exists, consists of up to two 
by the end user (using the LMS EUI), as well as by the text parts, the short and long abstract text, either or 
client application (using the LMS API). When a link is both of which may exist 

deleted from a link marker, LMS will automatically The link marker abstract short text data is intended to 

remove its other end from the link marker to which the 20 be brief descriptive text suitable for display on one line, 

other end was attached. When a link marker is deleted The link marker abstract long text data is intended for 

from a document, LMS will automatically delete all of use when it is desirable to provide more voluminous 

the links attached to it. When a document is deleted, information about the information that can be found at 

LMS will automatically delete all of the link markers the owning link marker location. This text can be as 

for that document. 25 much as several tens of thousands of characters, more 

The attributes of documents, link markers, and links for some national language characters sets. The long 

may be modified by the end user (using the LMS EUI) abstract text will only be presented to the end user upon 

and/or the client application (using the LMS API). For request, but it will always be examined during abstract 

example, the style, size, location, etc. of a link marker searches. If it is desirable, in anticipation of searches, to 

may be changed using these facilities. 30 specify keywords not otherwise in the text, a guideline 

Since all of the information regarding link markers, would be to place them at the end of the long abstract 

links, documents, and presenters is kept in a database as a courtesy to the end user who is probably more 

managed by LMS, LMS is able to determine which interested in reading the descriptive text first, 

presenter to launch with which document when the end A search may be initiated through either the LMS 

user attempts to follow a link. Since link markers get 35 EUI or LMS API. If initiated via the LMS EUI then 

and process their own messages with no client applica- the results (a list representing the candidate target link 

tion interaction (see the "Mouse processing" above), markers) will be displayed so that the end user may 

LMS can determine where links go (e.g., presenter P is examine them and, if so desired, selectively request that 

to render document D positioned, if necessary, to link the information represented in the list be displayed. If 

marker M) by querying the database, and, since LMS 40 initiated via the LMS API then a list of the candidate 

has the ability to launch (start) applications, LMS ena- target link markers is made available to the caller. Ei- 

bles end users to follow links without requiring any ther way, the limiting search parameters and search 

client application participation whatsoever. logic is the same (the LMS EUI internally uses the LMS 

Even though LMS goes to great lengths to offload API). Only data in the hypermedia LMS database will 

almost all of the work needed to provide hypermedia 45 be 'searched. If an end user or client application has 

support (and hence reduce client application coding added/modified/deleted any link marker text or link 

effort and development time), it is not desirable to pre- marker abstract data, but those changes have not (yet) 

vent client applications from being able to exert control been reflected in the database, then the changes will not 

over the behavior and data modifications of the hy- be reflected in the search results, 
permedia system. LMS provides this controllability 50 A search may be limited/qualified through the speci- 

through messages and Application Programming Inter- fication of any combination of four criteria; 

face (API). (1) The text string search parameter is the data which 

As previously mentioned, the LMS push-button style the search facility is to try and find in the database, 

of link marker has two substyles, one, which is **three (2) The upper/lower case character insensitivity 
dimensional" in appearance and has visual depression- 55 search parameter indicates whether or not the search 

movement when "pressed," and another, known as facility is to consider compared strings as matching 

"black and white," which is two dimensional in appear- when the only difference is one of upper/lower case, 

ance. Both of these can optionally be made to contain For example, whether or not "care for the young" 

text which would briefly describe that information should be considered as matching "Care For The 
which would be obtained if one or more of the link 60 Young" is determined by this parameter, 

marker's links were to be navigated (traversed). There- (3) The word alignment search parameter indicates 

fore the link marker's text, if present, can be thought of whether or not the search facility is to consider other- 

as a mini-abstract of the information located at the other wise matching strings as matches if the database data 

end of the link marker's links, and will be treated as such begins or ends other than at the beginning or end, re- 
by the search logic as described below. 65 spectively, of a text word. For example, whether or not 

In addition to the text contained in a link marker, a search parameter of "are for you" should be consid- 
LMS implements a link marker abstract object which is ered as matching database data of "prepare for youth- 
owned by the link marker. The link abstract data is ful" is determined by this parameter. 
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(4) The document identifier search parameter indi- 
cates whether or not the search facility is to limit the 
search to a particular document vs. doing a database- 
wide search. 

FIG. 30 shows an example of an LMS authoring 5 
dialog box. This is the user interface by which the sum- 
mary text data which constitutes the abstract for a link 
marker is entered into the LMS hypermedia database, 
FIG. 25 shows an example of an LMS abstract search 
request dialog box which is used to prompt a user to 10 
input search criteria for searching the LMS hypermedia 
database. Note that in addition to entering search text, 
the user is also prompted to optionally select search 
parameters. FIG. 31 shows an example of an LMS ab- 
stract search results dialog box. This dialog box pro- 15 
vides the user with a list of matches from the LMS 
hypermedia database where the search criteria was 
found. The user has the option in this dialog box to 
select one of the items displayed in the dialog box and, 
among other things, display the link marker abstract for 20 
that item, follow the link, and so on as indicated. 

The logic for how the hypermedia LMS database is 
searched is illustrated in the flow diagram of FIG. 32, to 
which reference is now made. The process begins in 
decision block 251 where a test is made to determine if 25 
the document identifier search parameter is null. If so, 
the LMS is invoked to lock the database in function 
block 252 and, in function block 253, the LMS builds a 
list of all document identifications in the database to be 
used a the search list. On the other hand, if the search 30 
parameter is not a null, the document is locked in the 
database in function block 254, as before, but, in func- 
tion block 255, the LMS builds a search list consisting of 
only the document identifier. 

Once the search list has been built by the LMS either 35 
in function block 253 or in function block 55, the pro- 
cess goes to function block 256 where the search is 
initialized by setting candidate list to empty. Then a test 
is made in decision block 257 to determine if this is the 
first document in the list or if, on a subsequent pass, 40 
there is another document in the list. Assuming for the 
moment, that this is either the first document or there is 
another document in the list, the LMS is called in func- 
tion block 258 to build a list of all link marker identifica- 
tions for the current document identification. Then, in 45 
decision block 259, a test is made to determine if this is 
the first or there is another link marker identification in 
the list. If not, the process loops back to decision block 
257 to build a list of link marker identifications for the 
next document in the list; otherwise, the LMS is called 50 
in function block 260 to get the link marker's data from 
the database. A further test in decision block 261 deter- 
mined if the current link marker has one or more links. 
If not, the process loops back to decision block 259 to 
retrieve the next link marker's data from the database; 55 
otherwise, a further test is made in decision block 262 to 
determine if the link marker's text matches the search 
parameter. If so, a test is made in decision block 263 to 
determine if this is the first link or if there is another link 
for the link marker. If so, a test is made in decision block 60 
264 to determine if the link's other end link marker 
identification is in the candidate list. If so, the process 
loops back to decision block 263; otherwise, the link's 
other end link marker identification is added to the 
candidate list in function block 265 before the process 65 
loops back to decision block 263. 

If the test in decision block 263 does not determine 
that this is the first or that there is another link for the 
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link marker, then the process goes to decision block 266 
where a test is made to determine if the link marker has 
an abstract and, if so, whether the search parameter is 
found in the abstract. Remember that it is optional for 
the end user to enter an abstract when a link marker is 
created. If the search parameter is found in an abstract 
for the link marker, a further test is made in decision 
block 267 to determine if the link marker's identification 
is in the candidate list. If so, the process loops back to 
decision block 259; otherwise, the link marker's identifi- 
cation is added to the candidate list in function block 
268 before the process loops back to decision block 259. 
Of course, if the link marker has no abstract, the process 
loops back to decision block 259 directly from decision 
block 266. 

In decision block 259, when it is determined that 
there are no other link marker identifications in the list, 
the process loops back to decision block 257, and now 
assuming that all documents and link markers in the 
search list have been examined, a further test is made in 
decision block 269 to determine if the search parameter 
is a null and, if so, the database is unlocked in function 
block 270 and the candidate list is returned in function 
block 271. If the search parameter is not a null, then the 
document is unlocked in the database in function block 
272 and the candidate list is returned in function block 
271. 

The search logic illustrated in the flow diagram of 
FIG. 32 is implemented in the pseudocode below, from 
which source code can be written in any suitable com- 
puter language. Preferably, the computer language 
should be an object-oriented language, and in one im- 
plementation of the invention, the C++ computer 
language was used. In the pseudocode, when the term 
compare is used in the logic description it is meant to 
include awareness of the above parameter rules con- 
cerning alignment and case insensitivity,. 



SEARCH LOGIC 

•If the document identifier search parameter is null 

-then invoke the LMS service for locking the 

database (prevent any modifications to the 

database by other processes); 

-else invoke the LMS service for locking the 

document specified by the document identifier 

search parameter in the database (prevent any 

modifications to the document in the database 

by other processes). 
END IF 

•BUILD A LIST OF DOCMUENT IDENTIFIERS OF THE 
DOCUMENTS TO BE SEARCHED . . . 

-If the document identifier search parameter is 

null 

•then invoke the LMS service for building a 
list of all document identifiers in the 
database; 

-else place only the document identifier 
search parameter in the list of documents 
to be searched. 
ENDIF 
END BUILD 

-BUILD A LIST OF CANDIDATE TARGET LINK MARK- 
ER IDENTIFIERS . . . 
•Set the candidate list to being empty. 
FOR EACH DOCUENT IDENTIFIER IN THE LIST . . . 
•Invoke the LMS service for building a list of 
all link marker identifiers for the 
current document identifier. 

•FOR EACH LINK MARKER IDENTIFIER IN THE 
LIST . . . 

-Invoke the LMS service for retrieving link 

marker data from the database. 

•If the link marker has one or more links 
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SEARCH LOGIC 



emanating from it then . . . 
•If the link marker contains text and 
the text compares equal to the search 
parameter text then . . . 
•FOR EACH LINK EMANATING FROM THE 
CURRENT LINK MARKER . . . 
•If the link's other end link 
marker identifier is not in the 
candidate list then 
-Add the other end link marker 
identifier to the candidate 
tel. 
ENDIF 
ENDFORLOOP 
ENDIF 

-If the link marker contains has an 
abstract, and the search parameter 
text compares equal to 
either the short or long abstract 
text, and the link marker identifier 
is not is the candidate list then 
-Add the link marker identifier to 
the candidate list. 
ENDIF 
ENDIF 
ENDFORLOOP 
ENDFORLOOP 
ENDBU1LD (The list of qualifying candidate link 
marker identifiers is now built) 
•If the document identifier search parameter is null 
-then invoke the LMS service for unlocking the 
database (permit modifications to the database 
by other processes); 

-else invoke the LMS service for unlocking the 
document specified by the document identifier 
search parameter in the database (permit 
modifications to the document in the database 
by other processes). 
ENDIF 

END aw SEARCH LOGIC 
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Trivial and obvious logic, concerning things such as 
checking for errors, etc., has been intentionally left out 
since it is not only obvious, but would also unnecessar- 
ily obscure the essence 6f the search logic for the 40 
reader. 

LMS provides a consistent end user interface across 
all client applications for hypermedia menus, dialog 
boxes, mouse processing, and link marker display man- 
agement. These facilities not only provide for the ap- 45 
pearance of these notions, but also result in the execu- 
tion of code to semantically satisfy the end user's re- 
quest. The functional relationship between LMS and an 
application and the EUI is illustrated, by way of sum- 
mary, in FIG. 33. The user may input commands, i.e., 50 
messages, in a variety of ways, as indicated by block 
284. These include a mouse, keyboard or LMS menus. 
The messages may first of all be input to an application 
program via an application window 285. These mes- 
sages are passed to the message processing code of the 
application 286 and, if the application chooses not to 
process the message, it is then sent to the message pro- 
cessing code of the LMS 287. An example is the genera- 
tion of menus, both pull-down and context. On the 
other hand, the messages may be LMS messages, in 60 
which case the message is passed directly to the LMS 
287. An example is when a link marker is selected. 

Link marker abstracts are owned by their respective 
link markers. The creation or modification of link 
marker abstracts is managed entirely by LMS. Both the 65 
creation and modification may be accomplished either 
via the LMS EUI and/or the LMS API. The created/- 
modified data will be stored into the LMS hypermedia 



database automatically whenever the rest of the data for 
the document, in which the link marker abstract's link 
marker resides, is saved. A link marker abstract will be 
automatically deleted from the LMS hypermedia data- 
base whenever the link marker that owns it is deleted 
from the database. 

While the invention has been described in terms of a 
single preferred embodiment, those skilled in the art 
will recognize that the invention can be practiced with 
modification within the spirit and scope of the appended 
claims. 

Having thus described our invention, what we claim 
as new and desire to secure by Letters Patent is as fol- 
lows: 

1. A method of providing hypermedia link marker 
abstract and search services in an open hypermedia 
system in which data for individual applications may be 
displayed on a screen of a display device in an applica- 

2Q tion window, each of said windows including a main 
application workspace in which said data is displayed, 
said hypermedia system providing a uniform and consis- 
tent graphical user interface for applications which 
utilize hypermedia services available from said open 
hypermedia system, said method comprising the steps 
of: 

providing an open hypermedia system which allows 
any application to participate in linking, allowing a 
seamless integration of applications and applica- 
tion-rendered data developed totally indepen- 
dently from one another; 
prompting a user to input information to create a link 
marker within an application window, said link 
marker being bidirectionally linked to one or more 
other link markers and/or unidirectionally linked 
to objects not written for said open hypermedia 
system; 

providing the user with an option to input a link 
marker abstract in the form of summary text associ- 
ated with the link marker; and 
maintaining a database of said link markers and link 
marker abstracts. 

2. The method recited in claim 1 wherein said link 
markers contain text indicating information located at 
other ends of the link marker's links. 

3. The method recited in claim 2 further comprising 
the steps of: 

displaying a dialog box on said display device for 

inputting data to be searched; 
searching said database link markers and abstracts in 

response to data input by a user; and 
displaying a list representing link markers in said 
database of data matching said input data. 

4. The method recited in claim 3 wherein said data 
input by a user is text which may be a keyword, phrase 
or sentence. 

. 5. The method recited in claim 3 further comprising 
the steps of: 

accepting a user input selecting a location in said list; 
and 

navigating to data in said database corresponding to a 

selected location in said list. 
6. The method recited in claim 5 wherein if said data 
in said database corresponding to a selected location in 
said list is data of a second application, further compris- 
ing the step of displaying said data within an application 
window of said second application. 
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7. The method recited in claim 6 wherein if said sec- 
ond application is not currently running, further com- 
prising the steps of: 

launching said second application; and 
opening an application window on said screen for 
said second application. 

8. A system providing hypermedia link marker ab- 
stract and search services comprising: 

an open hypermedia system which allows any appli- 
cation to participate in linking, allowing a seamless 
integration of applications and application-ren- 
dered data developed totally independently from 
one another, said open hypermedia system display- 
ing data for individual applications on a screen of a 
display device in an application window, each of 
said windows including a main application work- 
space in which said data is displayed, said hy- 
permedia system providing a uniform and consis- 
tent graphical user interface for applications which 20 
utilize hypermedia services available from said 
open hypermedia system; 

means for prompting a user to input information to 
create a link marker within an application window, 
said link marker being bidirectionally linked to one 
or more other link markers and/or unidirectionally 
linked to objects not written for said open hy- 
permedia system; 

means for providing the user with an option to input 
a link marker abstract in the form of summary text 
associated with the link marker; and 

means for maintaining a database of link markers and 
link marker abstracts. 
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9. The hypermedia system recited in claim 8 wherein 
said link markers contain text indicating information 
located at an end of the link marker's links. 

10. The hypermedia system recited in claim 9 further 
comprising: 

means for displaying a dialog box on the screen of 
said display device for inputting a user data to be 
searched; 

means for searching said database link markers and 
abstracts in response to data input by the user; and 
means for displaying on said screen a list representing 
link markers in said database of data matching said 
input data. 

11. The hypermedia system recited in claim 10, 
wherein said data input by a user is text which may be 
a keyword, phrase or sentence. 

12. The hypermedia system recited in claim 10 fur- 
ther comprising: 

means for accepting a user input selecting a location 

in said list; and 
means for navigating to data in said database corre- 
sponding to a selected location in said list. 

13. The hypermedia system recited in claim 12 fur- 
ther comprising means for displaying said data in said 
database corresponding to a selected location in said list 
within an application window of a second application if 
said data of said second application. 

14. The hypermedia system recited in claim 13 fur- 
ther comprising: 

means for launching said second application if said 

second application is not currently running; and 
means for opening an application window on said 

screen for said second application. 
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